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AUTOMATIC IMPLEMENTATION OF NETWORK CONFIGURATION CHANGES 



FIELD OF THE INVENTION 



The 



present 



invention 



relates 



generally 



to 



communication networks, and specifically to automated 
management of network connections. 



In modern networks, such as Asynchronous Transfer 
Mode (ATM) networks, the elements of the network use a 
management information base (MIB) to maintain common 
status and configuration information. The ATM MIB, for 
example, holds information concerning virtual path 
connections (VPCs) , virtual channel connections (VCCs) , 
registered services, registered ATM network prefixes and 
addresses, and capabilities available at ATM interfaces. 
All of the ATM devices in the network, such as switches 
and end-systems, use the MIB to determine how to conduct 
their network communications. 

In order to set up and maintain the MIB, the 
different ATM devices must exchange management 
information regarding status and configuration 
conditions. A variety of different methods and protocols 
for this information exchange have been developed. One 
commonly-used method is provided in the Integrated Local 
Management Interface (ILMI) Specification, Version 4.0, 
published by the ATM Forum Technical Committee 
(publication no. af-ilmi-0065 . 00, September, 1996), which 
is incorporated herein by reference. ILMI supports 
bi-directional exchange of ATM interface parameters 
between a pair of connected ATM interface management 
entities (IMEs) , so that each of the pair of IMEs can 
access the ATM interface MIB of its counterpart. Each 
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pair typically includes a network-side IME and a 
user-side IME (although within the network there are also 
syininetric IME pairs) . When a network device, such as a 
switch, has multiple ATM interfaces, it will likewise 
have multiple IMEs, one for each interface. 

When a change occurs in configuration or status 
information held by one of the IMEs in a pair, it sends a 
trap packet to its counterpart in order to report the 
change. Trap packets are the means specified by the 
Simple Network Management Protocol (SNMP) for reporting 
extraordinary events in a network. ■ SNMP is defined in 
Request for Comments (RFC) 1157 of the Internet 
Engineering Task Force (IETF), and is used by ILMI in 
management and control operations across ATM interfaces. 
Ordinarily, when the counterpart IME receives the trap 
packet, it reads the pertinent information from the 
sending IME in order to determine the configuration and 
status changes that have occurred. Trap packets are sent 
using the User Datagram Protocol (UDP) , which generally 
provides fast service but does not guarantee reliable 
delivery. Therefore, each IME periodically polls its 
counterpart in order to ensure that no traps have been 
missed. 

Digital Subscriber Line (DSL) is a modem technology 
that enables broadband digital data to be transmitted 
over twisted-pair wire, which is the type of 
infrastructure that links most home and small business 
subscribers to their telephone service providers, DSL 
modems . enable users to access digital networks at speeds 
tens to hundreds of times faster than current analog 
modems and basic ISDN service. DSL thus opens the most 
critical bottleneck in local-loop access to . high-speed 
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networks, and thus enables ATM service to be extended to 
client premises equipment (CPE) without requiring major 
investments in new infrastructure. A range of DSL 
standards have been defined, known generically as "xDSL, " 
wherein the various standards have different data rates 
and other associated features but share common principles 
of operation. 

DSL subscribers are connected to high-speed core 
networks through Digital Subscriber Line Access 
Multiplexer (DSLAM) systems. Because of the high cost of 
network bandwidth, a single DSLAM is typically designed 
to serve between 100 and 1000 clients and to concentrate 
their traffic through one or a few network trunks. (In 
the context of the present patent application, the 
inverse of the number of clients served by a multiplexer 
- between 1:100 and 1:1000 in the case of the typical 
DSIAM - is referred to as its concentration ratio.) 
Thus, to accord with the ILMI model described above, the 
DSLAM must maintain as many as 1000 network-side IMEs in 
order to serve all of its clients. As network use grows 
in the future, this figure may grow even higher. 
Concentration ■ ratios of this magnitude were not 
envisioned when the ILMI standard was developed. 
Adherence to the conventional ILMI model under these 
conditions would require both the DSLAM and the CPE to 
dedicate an excessive amount of computing power to 
interface management. 
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SUMMARY OF THE INVENTION 

It is an object of the present invention to provide 
improved methods and systems for network information 
management, particularly in the context of ATM interface 
management . 

It is a further object of some aspects of the 
present invention to provide methods of network interface 
management that are suited for use in access multiplexing 
systems that serve large numbers of clients. 

In preferred embodiments of the present invention, 
an access multiplexer, such as a DSLAM, provides access 
to a high-speed network, such as an ATM network, to a 
large number- of subscribers, each maintaining respective 
client premises equipment (CPE) . The multiplexer 

notifies the CPE of a change in network configuration or 
status by sending an appropriate trap packet to the CPE. 
In response to the trap packet, the CPE reads all of the 
relevant information in the MIB held by the multiplexer. 
The CPE then replaces the information in its own MIB 
accordingly. The multiplexer regards the read request 
that it receives from the CPE as an acknowledgment of the 
trap. When the multiplexer fails to receive the read 
request within a specified time limit, it resends the 
trap packet or, if necessary, resets its link with the 
CPE. 

Thus, the multiplexer verifies that every trap it 
sends is actually delivered to the CPE, despite the 
unreliable protocol used to send the trap packet. 
Consequently, it is not necessary for the CPE to poll the 
multiplexer, as in ILMI and other conventional network 
management models. This approach substantially reduces 
the computing burden placed on the multiplexer, as well 
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as simplifying the functionality of the CPE, by obviating 
the need for the CPE to poll the DSLAM and for the DSLAM 
to handle polling requests by hundreds or thousands of 
CPEs. 

There is therefore provided, in accordance with a 
preferred embodiment of the present invention, a method 
for network management, including: 

sending a trap message from a network end switch to 
client premises equipment (CPE) over a network connection 
therebetween, informing the CPE of a change in a network 
management information base (MIB) of the end switch; 

receiving a request from the CPE to the end switch, 
subsequent to the trap message, to read information from 
the MIB; 

providing the information from the end switch to the 
CPE responsive to the request; and 

determining the change to have been implemented by 
the CPE based on the request to read the information. 

Preferably, the CPE replaces old information 
recorded in a user MIB of the CPE with the information 
provided from the end switch, wherein the CPE replaces 
the old information with the provided information 
substantially in its entirety, without parsing the 
information for changes. 

Further preferably, receiving the request includes 
awaiting the request for a predetermined period of time, 
and sending the trap message includes re-sending the trap 
message if the request is not received within the 
predetermined period. Most preferably, re-sending the 
trap message includes making a predetermined number of 
attempts to re-send the trap message, and including 
sending a cold start message from the end switch to the 
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CPE to reset the connection if the request is not 
received after the predetermined number of attempts have 
been made. 

In a preferred embodiment, the network connection 
includes an Asynchronous Transfer Mode (ATM) network 
connection, and sending the trap message includes sending 
an ATM Integrated Local Management Interface (ILMI) trap 
message. Typically, the trap message includes a virtual 
channel/path connection (VCC/VPC) trap. Preferably, the 
network end switch includes an access multiplexer, and 
the CPE includes one of a plurality of client equipment 
installations serviced by the multiplexer. Most 
preferably, the access multiplexer includes a Digital 
Subscriber Line Access Multiplexer (DSLAM) , wherein the 
DSLAM is adapted to service at least one hundred of the 
client equipment installations. 

Preferably, sending the trap message includes 
sending multiple trap messages regarding multiple changes 
in the MIB, and receiving the request includes receiving 
multiple read requests from the CPE to read the 
information from the MIB, each such read request 
subsequent to a respective one of the trap messages, and 
determining the change to have been implemented includes 
verifying, responsive to the requests, that all of the 
changes have been implemented without the CPE having 
polled the end switch for further trap messages. 

There is also provided, in accordance with a 
preferred embodiment of the present invention, network 
access, multiplexing apparatus, including: 

a plurality of interface connections, linking the 
apparatus to client premises equipment (CPE) at multiple 
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client premises, so as to provide access via the 
apparatus to a high-speed network; 

a meinory, adapted to store a network management 
information base (MIB) / and 

a management processor, adapted to send a trap 
message to the CPE over one of the interface connections 
therebetween informing the CPE of a change in the MIB, to 
receive a request from the CPE subsequent to the trap 
message to read information from the MIB, to provide the 
information to the CPE responsive to the request, and to 
determine the change to have been implemented by the CPE 
based on the request to read the information. 

There is additionally provided, in accordance with a 
preferred embodiment of the present invention, client 
premises equipment (CPE), which is adapted to receive a 
trap message from a network end switch over a network 
connection therebetween, informing the CPE of a change in 
a network management information base (MIB) of the end 
switch, and responsive to the trap message, to read 
information from the MIB without polling the end switch 
for further trap messages. 

The present invention will be more fully understood 
from the following detailed description of the preferred 
embodiments thereof, taken together with the drawings in 
which : 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram that schematically 
illustrates a network access multiplexing system, in 
accordance with a preferred embodiment of the present 
invention; 

Fig. 2 is a block diagram that schematically 
illustrates interface management entities in the system 
of Fig. 1, in accordance with a preferred embodiment of 
the present invention; and 

Fig. 3 is a flow chart that schematically 
illustrates a method for updating network configuration 
information held by client premises equipment, in 
accordance with a preferred embodiment of the present 
invention . 



8 



38540S2 



DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

Fig. 1 is a block diagram that schematically 
illustrates a network access multiplexing system 20, in 
accordance with a preferred embodiment of the present 
invention. A DSLAM 22 comprises multiple interface 
connections, providing access to a network 24 for .a 
plurality of subscribers having respective client 
premises equipment (CPE) 26. Network 24 preferably 
comprises an ATM network, and CPE 2 6 is configured to 
provide ATM service directly to the subscriber premises. 

Fig. 2 is a block diagram that schematically shows 
interface management features of DSLAM 22 and of one of 
CPEs 26, in accordance with a preferred embodiment of the 
present invention. In accordance with the ILMI model, 
the connection between DSLAM 22 and CPE 2 6 is managed by 
a pair of IMEs: a network-side IME 30 maintained by the 
DSLAM, and a user-side IME 32 maintained by the CPE. The 
IMEs typically comprise central processing units (CPUs) 
running suitable network management software (frequently 
in addition to other tasks carried out by the CPUs) . 
IMEs 30 and 32 maintain respective MIBs 36 and 38 in 
memory associated with the CPUs. The MIBs hold network 
configuration and status information, including tables of 
VPCs, VCCs, registered services, etc., as is known in the 
art. A similar pair of IMEs exists for each of the other 
CPE-DSIAM connections, so that typically, IME 30 is one 
of between 100 and 1000 IMEs maintained by the DSLAM. In 
addition, the DSIAM has a network or element management 
system 34, which serves as its user-side IME vis-a-vis a 
network device, such as a core switch, with which the 
DSLAM communicates over a trunk of ATM network 24. 
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Fig, -3 is a flow chart that schematically 
illustrates a method, by which network IME 30 of DSLAM 22 
notifies user IME 32 of CPE 26 of a status or 
configuration change in MIB 36, in accordance with a 
preferred embodiment of the present invention. Although 
this method relates explicitly to VCC changes, it is 
equally applicable, mutatis mutandis, to VPC changes. 
IME 30 sends a VCC change trap to IME 32, as defined by 
the ILMI standard, at a trap issuance step 40. Normally, 
IME 32 receives the trap, and responds with a request to 
IME 30 to read the service and VCC tables held in MIB 36. 
User IME 32 does not poll network IME 30. Rather, it 
simply reads all information from MIB 36 that is 
associated with the virtual channel (VC) indicated by the 
VCC change trap. Upon reading this information, IME 32 
clears all of the all of the information regarding this 
virtual channel (VC) from its own MIB 38, and replaces it 
with the fresh information read from MIB 36. This 
approach may be less efficient than methods of 
configuration updating that are used conventionally, but 
it avoids difficulties that can be caused by having to 
parse complex changes and thus simplifies the handling of 
such changes in multi-client environments such as system 
20. 

When network IME 30 receives the read request from 
user IME 32, it treats the request as an acknowledgment 
that IME 32 received the trap packet, at an 
acknowledgment step 42. Thus, at this point, after IME 
32 has read the pertinent information, handling of the 
status or configuration change by IME 30 is finished. 

If at step 42, network IME 30 does not receive a 
read request from user IME 32 within a specified period 



38540S2 



of time, it assumes the trap packet to have been lost. 
Preferably, the specified period is no less than 30 sec. 
In this case, IME 30 will return to step 40 and send the 
trap again. This re-send is preferably repeated up to a 
preset maximum number of attempts, at 3l retry limit step 
44. Most preferably, at least two attempts are made. 

When the retry limit is exceeded, network IME 30 
sends a cold start trap to user IME 32, as specified by 
the ILMI standard, at a cold start step 46. The cold 
start trap resynchronizes the connection between DSLAM 22 
and CPE 26. Optionally, IME 30 notifies network/element 
management system 34 that a cold start has taken place. 
At this stage, again, network IME 30 waits for an 
appropriate read request from user IME 32, at a response 
step 48. When the read request is received, IME 30 
assumes the cold start to have been received, 
acknowledged and implemented by IME 32. MIB 38 of CPE 26 
is reset, along with the portion of MIB 36 of DSLAM 22 
that relates to this particular CPE, and the process of 
handling the status or configuration change is done. 

If network IME 30 still receives no response to the 
cold start at step 48, it concludes that CPE 26 is 
incapable of responding, presumably due to a serious 
fault. In this case, IME 30 notifies network/element 
management system 34 of the fault and awaits appropriate 
service . 

Although preferred embodiments are described herein 
with particular reference to the ILMI specification, the 
extension of the methods and concepts described herein to 
other standards for management information exchange will 
be apparent to those skilled in the art. More generally, 
while these preferred embodiments relate to ATM networks 
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and DSLAM systems for communication over such networks, 
the principles of the present invention are similarly 
applicable to management of other types of networks, such 
as Internet Protocol (IP) networks. It will thus be 
appreciated that the preferred embodiment described above 
is cited by way of example, and that the present 
invention is not limited to what has been particularly 
shown and described hereinabove. Rather, the scope of 
the present invention includes both combinations and 
subcombinations of the various features described 
hereinabove, as well as variations and modifications 
thereof which would occur to persons skilled in the art 
upon reading the foregoing description and which are not 
disclosed in the prior art. 



